Vendor the 0.54.1 prometheus dependency to avoid conflict with Agent/EDOT #42890
Conversation
botelastic
bot
added
the
needs_team
|
This pull request does not have a backport label.
To fixup this pull request, you need to add the backport labels for the needed
|
|
We also have Prometheus metricbeat code in x-pack x-pack/metricbeat/module/prometheus That would need library changes as well. |
|
@ishleenk17 there's no usages of the github.com/prometheus/prometheus lib there. if there were any remaining imports they would fail anyway. either way it doesn't matter, this PR is no longer required. the beats dependency in agent is being removed, which solves the problem of the mismatched otel dep. |
cmacknz
added
backport-8.x
|
Re-opened, we are going to need this to restore Beats receivers in the 9.0 branch and allow us to keep them in 8.18. |
tommyers-elastic
force-pushed
the
vendor-prometheus2-dep
branch
2 times, most recently
from
9d6990c to
fac1123
Compare
… with Otel collector deps in elastic agent.
[git-generate]
# this is pretty nasty, but it's the best way i could find to reliably get only the required source
#
# the way the whole thing works in general is: in go.mod, you replace the module you want to vendor
# with a different name, using the major version suffix notation. you then add a 'replace' statement
# which points to a local copy of that module at a specific version.
#
# this script will not work if the module you are trying to vendor is already vendored. before running
# it, the module you wish to vendor should currently be used as-is in the beats source. if you need to
# update an already vendored module, you should first 'un-vendor' it, then run this script fresh.
#
# when you're ready, run this script from the root go module directory.
module=github.com/prometheus/prometheus
version=v0.54.1
go_import_path=${module}@${version}
go_mod_path=https://raw.githubusercontent.com/prometheus/prometheus/refs/tags/${version}/go.mod
# ensure the correct version is in the root go.mod file so the right sources are downloaded in the next step
go get ${go_import_path}
# there's no way to selectively vendor, so we have to get everything ...
go mod vendor
# copy our module to a non-go-managed vendor directory and add a go.mod
mkdir -p _vendor/${go_import_path}
cp -R vendor/${module}/ _vendor/${go_import_path}
curl ${go_mod_path} -o _vendor/${go_import_path}/go.mod
pushd _vendor/${go_import_path}
# this removes unnecessary dependencies from the vendored source
go mod tidy
popd
rm -r vendor
# update go.mod with the vendored module
go mod edit -droprequire=${module}
go mod edit -require=${module}/v2@v2.54.1
go mod edit -replace=${module}/v2=./_vendor/${go_import_path}
# replace the existing imports
grep -Rl --include="*.go" ${module} | xargs sed -i "" "s|${module}|${module}/v2|g"
go mod tidy
tommyers-elastic
force-pushed
the
vendor-prometheus2-dep
branch
from
fac1123 to
f4a1d30
Compare
pierrehilbert
added
the
Team:Elastic-Agent-Data-Plane
botelastic
bot
removed
the
needs_team
|
Pinging @elastic/elastic-agent-data-plane (Team:Elastic-Agent-Data-Plane) |
pierrehilbert
added
the
Team:obs-ds-hosted-services
pierrehilbert
added
needs_team
|
Pinging @elastic/obs-ds-hosted-services (Team:obs-ds-hosted-services) |
botelastic
bot
removed
the
needs_team
|
This pull request doesn't have a |
|
/test |
|
@tommyers-elastic This could lead to issues for repos that depends on beats. #39840 (see the PR's description) See: golang/go#30354 (comment) So, what most probably will happen here is that those repos will start breaking because |
|
closing due to issues this would cause with upstream beats dependencies golang/go#30354 (comment) |
The context here, in short, is - Elastic Agent includes OTel Collector, which has a dependency on prometheus v3.x. Elastic Agent also includes Beats (as a go dependency, not just in the bundle), which has a dependency on prometheus v2.x. Due to some potentially breaking changes in the upgrade between prometheus 2 and 3, we need to vendor the prometheus 2 dependency into Beats for a short period of time.
The changes here are generated from the script in the commit message. It's not ideal, but it's the only way I could find to make a 'go mod vendor'-esque output for a single module.
This is a short term situation whilst we spend the time properly validating the prometheus 2->3 changes.
Checklist
CHANGELOG.next.asciidocorCHANGELOG-developer.next.asciidoc.Disruptive User Impact
Author's Checklist
How to test this PR locally
Related issues
Use cases
Screenshots
Logs